【レポート】Billion Transactions: Reaching new limits@PayPay #AWSSummit

AWS Summit Online Japan 2020

#レポート

#AWS

もこ

2020.09.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

どうも、もこ@札幌オフィスです。

今年はAWS Summit Onlineという事で、2020/9/8〜9/9の間のライブセッションと、9/30まで視聴可能なAWS認定セッション、お客様事例セッション、セルフペースハンズオン、Partner Discovery Session (パートナーセッション) などなど、場所を選ばずにオンラインで、好きな時に好きなだけ学べるような環境になっています。

本記事はオンデマンドセッション「CUS-66：Billion Transactions: Reaching new limits@PayPay」のセッションレポートとなります。

セッション概要

PayPay 株式会社 SRE Team Tech Lead Harsh Prasad 氏

PayPay 株式会社 Platform Team Product Division Platform Engineer Kuria Robert Kamau 氏

PayPay 株式会社 Payments Team Sr. Software Engineer Ayush Mittal 氏

With a sky rocketing user base and transaction volumes, it is our ultimate goal at PayPay to put our users first and give them an even better experience without any compromises. Our session entails how we have adapted and evolved various approaches such as choice of databases, traffic replay based performance tuning, log management among others to realize our goal.

セッションレポート

Agenda

PayPayについて
PayPayにおけるパフォーマンス改善とスケーラビリティ
システム移行から学んだこと
Amazon Elasticsearch Service(Amazon ES)を利用したログ基盤

PayPayについて

QRコード決済サービスで、たった1つのアプリでオフラインストア、オンラインストアで支払いが出来る
2018年10月5日にローンチ
ローンチから驚くほど成長
2020年6月には3000万ユーザーと230万店舗がPayPayを導入
成長ペースは爆発的

PayPayはオフライン決済だけではない
- オンライン決済
- 公共料金支払い
- P2P
- PayPayピックアップ(新サービス)
2020年4月には累積決済数が10億件を突破
- ローンチ以来急成長を見せている

PayPayにおけるパフォーマンス改善とスケーラビリティ

この爆発的成長にPayPayのバックエンドはどのように対応したか？
- パフォーマンス改善における最大の問題は「解」より「問」が多すぎる点
  - どのようにキャパシティーを測定するのか？
  - ボトルネックはどこにあるのか？
  - 最適なソリューションはどれなのか？
PayPayのテック・スタック
- テック・スタックはAWSに基づいている
- PayPayはElastic Load Balancingを利用してGlobal Acceleratorに接続して、Amazon EC2にデプロイされたKubernetesクラスターにリクエストを渡す
- PayPayのデータベースやセキュリティ、データレイクなどすべてにおいてAWSのマネージドサービスが迅速カツ便利なソリューションを提供
- Argo CDとJenkinsを利用した社内管理のCI/CDもある
- ELKスタックを利用
- Amazon ESを利用してログを記録

どうやってシステムのキャパシティを測定するのか
- システムのキャパシティを測定するためにProd環境の完全なレプリカを作成した
- アーキテクチャ、コンポーネント、サービス全く同じ環境で、Perf環境と呼んでいる
- 環境はTerraformを利用しているため、簡単に同じ環境を作れた
- Amazon Aurora / Amazon RDSは定期的に実施するバックアップから自動リストア
- 環境全体の自動作成によるコスト管理も可能に
- 数時間しかかからずに可能
ボトルネックの特定
- ボトルネックを見つけるためには、インフラだけではなく負荷の再現も必要
- GoReplayなどのツールを利用して本番環境のトラフィックを捕捉
- Amazon S3とAmazon MSKのサポートにより人の操作なしでストレージオプションからキャプチャされたトラフィックをリプレイすることができる
- Perf環境でトラフィックを再現することでボトルネックがどこで発生しどのサービスに問題があるかを明確に把握出来る
- 消費者や店舗のリクエストをGoReplayシステムでトラフィックキャプチャした
- キャプチャされたトラフィックのデータはマスクされるためユーザー情報は表示されずにAmazon S3に保存出来る
- 本番データベースはマスキングしてPerfデータベースに複製される
  - 個人情報・ユーザー情報が見えないようにマスキング
- Amazon S3にデータが作成されるとGoReplayはAmazon S3からリクエストを取得して、Perf環境で同じトラフィックを再現出来る

GoReplayは非常に野心的なアプローチだったが、本番のトラフィックを完全に複製するには様々なハードルがあった
- ユーザー情報をマスキングするためのロジック
  - リクエストとデータベースに情報をマスキングする必要がある
  - 一貫してマスキングされていることを確認するには多くの作業が必要
- マスキングされたユーザーのoauthサービスの設定をするのも多くの作業が必要
- GET/PUTリクエスト自体の処理は異なる環境で生成されたUUIDと本番環境とで一致しないため、非常に面倒な作業になる
アプリケーションとインフラの可観測性を高めた
- カスタムメトリックを導入してアプリケーション監視をさらに改善
- JMeterやGatlingなどの負荷テストツールを利用してどのサービスやインフラがボトルネックとなっているのかを特定
- AWSはボトルネックを発見するためのツールをたくさん提供している
  - Amazon CloudWatch Metrics
  - Amazon Aurora Performance Insights
  - その他の監視ツールとのインテグレーション
ボトルネックが見つかったらどのソリューションが最適かを考える
- AWSが実際にインフラを即時にon-the-flyで拡張、設定するための強力なツールを提供している
- 新しい尾設計、新しいアーキテクチャを本番リリース前にパフォーマンス環境でテスト出来るようになったため非常に簡単
- 各種要件に合わせてAWSが提供するさまざまな管理リソースを試してみたが非常に簡単で非常に信頼性の高い物だった
データベースソリューションの検証
- すでにあるデータベースを他のデータベースにすべて変更する場合、本番環境で行うのは手間が掛かり大きな問題
  - "P6SPY"を利用してデータベースのトラフィックを再生
    - データベースコマンド/データベースクエリをAmazon MSKにPublishするLog4j統合
  - Amaozn MSKからMulti Thread Consumerが、古いデータベース、既存のデータベース、新しいデータベースに対してクエリを実行する
  - データ自体が信頼できるかどうか、アプリケーションやクエリ自体との統合に問題が無いかを確認
  - 最終状態のデータの整合性を確認するために、Amazon EMRを利用して古いインスタンスと新しいインスタンスの間でデータを比較
  - EMRを使うとフィールド値、データベーススキーマも比較出来る
  - 統合に問題がある場合は簡単に比較して不一致を見つけて、一致させることが出来る
    - EMRからE Mail / Slackなどに通知する事も出来る

大容量向けAWSソリューション
- PayPayのデータは事業成長に伴い何倍にも膨れ上がった
- 各データベースには数10TBのデータがある
- そこで照合して、データ検証をするので、大変なタスクとなる
- データ量が増加するとデータ検証を時間無いに完了するには多くの技術的な力が必要
- Amazon EMRとDynamoDB Streamを検証に利用した
  - セットアップが非常に簡単で強力
  - 既存のデータベース内のデータの一致や不整合を簡単に比較して、それに応じて通知したり修正出来る

システム移行から学んだこと(PayPayでのシステム移行)

PayPayで行っているシステムの移行システムについてと、現在行っている作業、これから計画してる作業について話す
Agenda
- PayPay利用レポート
  - 古いアーキテクチャ
  - 課題
  - 解決策
  - システム移行
- データ突合処理
  - 古いアーキテクチャ
  - 新しいアーキテクチャ
PayPay利用レポート
- ユーザーがPayPayの利用履歴の概要を見たい場合など
  - 最近6ヶ月の利用状況の要約を見れる
  - ユーザーが受け取れるキャッシュバックの金額、過去6ヶ月の月次支払金額、最もよく利用した店舗なども確認できる
  - 見たい日付を指定したりも出来る
  - 例えば過去1ヶ月に使った金額、決済の種類、支払いの種類などに利用するレポートなど

古いアーキテクチャ
- PayPayは基本的にイベント駆動型モデルであり、マイクロサービスアーキテクチャにもとづいている
- PayPayで支払いが行われるたびにメッセージがKafkaに送信される
- Consumerがメッセージを利用してデータベースにデータを書き込む
- データベースからデータをフェッチして応答するRead Serviceもある
PayPayの利用状況の概要については異なるユースケースが発生している
- 過去6ヶ月分のクレジットの概要、キャッシュバックの概要、よく利用する店舗を表示する必要がある
- OLAPユースケースと呼んでいる
- データベースに対してOLAPクエリを直接実行してデータを取得
- 基本的な問題とは？
  - ユーザー、各ユーザーの決済数が増加している
    - システムがユーザーの次のターゲットポイントや、決済数に対してスケーラブルではない

課題
- 過去のデータサマリー、計算値は変わらないのに、各要求に対して毎回複数の重いOLAPクエリを実行している
- ホットユーザーの場合、スキャンされる行数が非常に多いため、mysqlスレッドがビジー状態になり、読み取りがタイムアウトしてしまい、UXに影響を与える
通常ユーザーはPayPayでの決済数が通常であるユーザー
- ホットユーザーはPayPayのヘビーユーザー、多くの決済履歴がある
- ホットユーザーが大量のOLAPクエリをリクエストすると多くのDBリソースを消費してしまう
解決策
- 前日のデータを集計して別のデータストアへ保存してクエリ頻度を下げる
- 増加するトランザクション数とホットユーザーに対応する分散集約システムを設計する
  - 前日のデータ集計を保存するような分散型のシステムを設計
  - Amazon EMRを利用して時間を掛けずに済む
- 中央データの保存には一貫性のある永続的なストレージが必要
  - Amazon S3を利用
  - Amazon EMRを利用しているためHDFSを利用出来るがAmazon S3を利用する
  - 永続的なストレージであり、デバッグの面でもAmazon S3のデータを直接参照するのに非常に便利
- イベント駆動型モデルを利用して、障害発生時にデータを再度集約できるようにし、】再度フェッチするのにかかるDBコストを節約する
  - PayPayは既にイベント駆動型モデルなのでこちらでも採用
  - Pub Subモデルを利用
  - 障害が発生した場合にS3から再度パブリッシュすることが可能
- 信頼性を高め、ロルバック戦略として機能するように、トラフィックを新しいシステムは重み付けルーティングするルーターシステムを設計する
  - PayPay利用履歴のトラフィックを新しいシステムに100%直接移行することはできない
  - プロキシシステムでどれくらいのトラフィックを流すのかを設定出来るように
  - 新しいサービスが負荷、パフォーマンス、データーベース、クエリーに問題が発生した場合などにプロキシシステムがトラフィックを古いサービスに切り替えるように
  - 0%→1%→5%→10% と切り替えて徐々に100%に移行するようにする予定
新しいアーキテクチャ
- 基本的にはAmazon EMRとAmazon S3を利用
- EMRは2つのジョブを用意
  1. データベースからデータをフェッチするジョブ、ユーザーの各時間単位のデータを事前集計してAmazon S3に保存
  2. Amazon S3から時間単位のデータをフェッチして1日の集計を行い最終的な集計データをKafkaに送信
- 集計データを事前に計算してデータベースに保存する事によって古いアーキテクチャの問題であったクエリを解決
- プロキシシステム
  - 設定された重み付けに元図居てトラフィックを切り替えてくれる

データの照合(突合処理)
- PayPayはメッセージに依存するヘビーなイベント駆動型システム
- データの一貫性は非常に重要になる
- 古いアーキテクチャ
  - 現在のアーキテクチャではSpringバッチジョブなどを利用している
  - 2つのデータベース間の照合を行っている
    - 非常に遅い
  - シリアル方式で処理を行う
  - スケーラブルではないので新しいシステムへの移行を考えた

新しいアーキテクチャではEMRを利用
- 以前はシリアル方式でやっていた
- Amazon EMRに切り替えることで分散処理が出来るように
- 複数のデータベースで同時にデータ照合を行うことが出来るようになった

100以上のマイクロサービスを提供するようになった
1日あたり3TBのログが生成される
次のStepではPayPayがどのようにログを処理しているのかについて話していく

Amazon Elasticsearch Service(Amazon ES)を利用したログ基盤

Agenda
- 主なログの種類
- ログETLの概要
- クラスタとインデックスのサイズ
- 課題
- Amazon Elasticsearch UltraWarm
- 今後のESの取り組み
主なログの種類
- Application Logs
  - PayPayアプリを構成するマイクロサービスのログ
  - マイクロサービスはEC2のSelf Hosted Kubernetes Clusterで実行されている
- k8s Cluster Logs
- TiDB Logs
Kubernetes LogsとTiDB Logsは運用とクラスターのトラブルシューティングに利用
Application Logsはトラブルシューティングとビジネスサポートの両方を目的としている
ログETLの概要
- ETLをログSLAに基づいて実行する必要がある
- Application LogsはKubernetesで実行されている各マイクロサービスにLog4jを設定して、ログをKafkaに送信
- Logstashとインデックスを利用してKafkaからログを取得して検索のためにAmazon ESに保存、アーカイブのためのAmazon S3 両方に送信
- Amazon ESでは30日間保存していて検索出来るようにしている
- 30日より古いログはAthenaを利用する
- Kubernetes/TiDB logsはFluentdでAmazon ESに直接インデックス
  - 30日間保存しているがアーカイブはされない
- Application Logsはトラブルシューティング以外にもビジネスサポートにも利用されるため、SLAが高く異なるETLにも対応している

Amazon ESクラスタとインデックスのサイズ
- アプリケーション&k8sログクラスター(共有)とTiDBログクラスター(専用)の2つのクラスターがある
- アプリケーション&k8sログクラスター(共有)
  - 120以上のマイクロサービスのログ連携
  - 57ノード(3つのマスターノード、54のデータノード)
  - 329TBのクラスター容量
  - アプリケーションログインデックスは約2.8TB/日(レプリカを含めると実質5.6TB)
  - Kubernetesのログは一日あたり約500GB
- TiDBログクラスター(専用)
  - 1つのTiDBクラスターからのログ
  - 9ノード(3つのマスタノード、6つのデータノード)
  - 36TBの総容量
  - 一日あたり100GB(レプリカ含めると実質200GB)
- これらのクラスター両方でr5.4xlargeを利用
  - EBSの最大サイズは6.1TB
課題
- ログ量の増加
  - PayPayはものすごいスピードで成長していて新しいマイクロサービスが増えて行っている
  - 右のグラフは2ヶ月、月平均で600GBの増加
  - ログが増加しても常に同じSLAを維持するためにインデックス設定を頻繁にチューニングしたりデータ列を増やしたり、時にはKibanaで検索可能なログ期間を短縮する必要があった
  - これらのログの量、クラスタの量では構成変更も難しくなってくる
- AthenaとKibanaで異なるログ検索の経験
  - アーカイブのログ検索にAthenaを導入
  - 全文検索のKibanaに慣れているユーザーにとってはAthenaを使うのが難しい
    - Kibanaのような検索をしようとするとイライラしてしまう
- Amazon ESクラスター構成変更を行ったときも問題に直面
  - データサイズによってはKibanaのダウンタイムが長くなる
  - 前回は7時間近く掛かった

Amazon Elasticsearch Service UltraWarm
- 発表以来非常に待ち望んでいた
- UltraWarmはAmazon ESのストレージ機能として読み取り専用のウォームティアーを導入した新しいソフトストレージ機能
- UltraWarmが発表される前はEBSまたはインスタンスストアのHot Tier Storageしかなかった
- 古いデータはAmazon S3にしかアーカイブできなかった
- UltraWarmを利用すると、コールドまたは古いデータインデックスをAmazon S3ベースに読み取り専用ストレージに格納しKibanaから検索出来るようになる
- ウォームティアーノードのノードあたりのストレージサイズ
  - EBSの最大量は6.1TBだが、UltraWarmは20TBもある
- ホットからウォームアップまで、もしくはウォームからホットまでティア冠でデータやインデックスを簡単に移行出来る
- 1つのPOST APIと同じくらい作業が簡単で、階層間でのインデックス作成、移行、管理を自動化出来る
- おかげで UltraWarmは "Perfect Solution for use case"になった
- データ量が増加した場合などの問題や課題のほとんどを解決してくれた

UltraWarmを導入して月々のコストを約40%削減
- UltraWarm導入前
  - 57クラスターノード
  - Kibanaで検索出来るのは最大1ヶ月
- UltraWarm導入後
  - 20クラスターノード
    - Master Node:3
    - Hot Tier: 6
    - Warm Tier: 11
  - Kibanaで3ヶ月検索可能に
    - Hot Tier: 1週間
    - Warm Tier: 3ヶ月
今後のESの取り組み
- Amazon ESでのログ記録をより便利にするクールな機能を利用して、ファイル形式をtextからParquetに変更することでAthenaのパフォーマンスを向上させる
- Amazon Cognito / Oktaと統合して、Kibanaのセキュリティー向上
- Anazib ESの新バージョンと新機能を試して、Amazon ESドキュメントをチューニングしてさらに最適化し、Amazon ESストレージを改善していきたい